Gopher is one of the most useful Internet services available, and it is widely used by
beginner and veteran alike. Gopher is a menu-based file location system, which leads you
through a series of hierarchical menus to find specific files you want. Setting up a
Gopher site is really just a matter of configuring the Gopher server software and creating
a number of logical directory structures with files indexed in a Gopher format.
Gopher works by having a client program started by a user connect to a Gopher server
and retrieve information about files available on the Internet (or local area network, if
the Gopher server is limited to that area). At the end of 1995, there were more than 6,000
Gopher servers on the Internet, all accessible by anyone with a Gopher client. Those
servers contain information about more than 10 million items, ranging from text files to
movies, sounds, images, and many types of application binaries. Gopher enables you to
display and manipulate lists of files, looking for items of interest to you.
If you or the users of your Linux system want to connect to another Gopher server, you
need a Gopher client. There are several clients available with Linux distributions, on FTP
and BBS sites, and through several other sources. If you don't want to allow users (or
yourself) to start a Gopher client, you can use Telnet to connect to sites known as public
Gopher clients. These sites allow you to log in as an anonymous user and access the Gopher
system. Most Gopher client packages offer more than just Gopher, as well. Typical Gopher
clients enable you to access WAIS indexes, use FTP, and to some extent, work with the
World Wide Web.
This chapter looks at how you can set up a Gopher server, allowing others to access
your machine's Gopher listings. Although the chapter won't go into detail about how you
should structure your Gopher service, you will see how to configure your software.
Currently two versions of Gopher are available for Linux systems: Gopher and Gopher+
(Gopher Plus). Gopher is freely available, but Gopher+ is a commercial product. The
difference between the two is functionality. If Gopher+'s additional capabilities are
important to you and your Gopher site, you may want to consider purchasing the product.
Essentially, Gopher+ adds the following features:
Gopher+ works with Gopher, but Gopher cannot use the advanced features of Gopher+.
Gopher+ also works with WWW browsers, while Gopher doesn't always function well in a
graphical browser. Gopher+ licenses tend to cost about $100 or $500, depending on the
site's conditions.
The versions of Gopher usually offered with Linux come from one of two sources:
University of Minnesota Gopher and Gopher+, or GN Public License Gopher. The last public
version of UM Gopher was version 1.3 (version 2.13 is free only to educational
institutions), but the University is no longer working on the freeware Gopher product,
concentrating instead on the commercial Gopher+ product. The GN Public License Gopher
includes a WWW service, but it does not provide a full functionality at present.
Gopher uses a TCP/IP family protocol known, surprisingly enough, as the Gopher
protocol. This is a fairly simple request-answer protocol that is implemented for speed.
When Gopher transfers information about a file it knows about (called a Gopher menu file),
it follows a set format. The format used by Gopher is:
<type><display_name><selector string><hostname><port>
The fields in the Gopher menu file have the following meanings:
| type | This field is a a one character description of the item (see the next list for valid codes). |
| display_name | This field is the the menu or display name, followed by a tab character. |
| selector_string | This field is a unique identifier for a document on each server (usually based on the filename). The selector string is followed by a tab character. |
| hostname | This field is the host where the file resides, followed by a tab character. |
| port | This field is the port to access the host, followed by a carriage return/line feed pair (usually port 70). |
The Gopher+ version of the system adds a few new attributes to each line, including the
name of the system administrator responsible for the service, a simple description of the
document type (text, for example), the language the file was written in, the last date the
file was updated, and the size in bytes.
When a file is to be retrieved through the Gopher system, the hostname and port are
used to create the connection to the remote, while the selector string can be used to
identify the file to be downloaded.
Several types of files are supported by Gopher, all given a unique one-character type
code. Valid codes are:
| 0 | Plain text file |
| 1 | Gopher directory |
| 2 | CSO phone-book server (the hostname is the machine to connect to, the selector string is blank) |
| 3 | Error |
| 4 | BinHex Macintosh file |
| 5 | Binary DOS archive file |
| 6 | UNIX Uuencoded file |
| 7 | Index-search server |
| 8 | Pointer to text-based Telnet session (hostname is machine name to connect to and selector string is name to log in as) |
| 9 | Binary file |
| g | GIF file |
| h | HTML document |
| I | Graphic image |
| I | Unselectable inline text |
| M | MIME encapsulated mail document |
| P | Adobe PDF file |
| s | Sound |
| T | Pointer to 3270 Telnet session (hostname is machine to connect to and selector string is login name) |
You must have the following files on your Linux system for Gopher to work:
You can modify these requirements if you have a private site (such as for your local
area network). If you are offering open access, you should have all the components.
Installing and configuring Gopher (and Gopher+) is a matter of setting a number of
configuration options prior to compiling the system software (it is usually not
precompiled for you) and configuring some standard files. Gopher+ installation is done in
the same manner, although with some extra parameters. Because Gopher is more likely to be
on a Linux site than Gopher+, this chapter concentrates on Gopher.
This section uses filenames without full path extensions because it really doesn't
matter where you install the Gopher software, as long as the directory paths are set
correctly. There is no defined standard configuration for directory locations, so feel
free to choose whatever works best for you.
The configuration parameters for Gopher (and Gopher+) are in a file called
gopherd.conf, which is read by the Gopher daemon gopherd. The default settings generally
need a little modification, although many changes are simply changing commented lines to
uncommented, and vice versa.
The first step is to create an alias for the Gopher service on your machine. You can do
this with the line that defines the hostalias. There should be a line in the file that
looks like this:
hostalias: tpci
The alias is used to find the Gopher server on your system, and it should not be
directly tied to a real machine to allow you to make changes whenever you want. The best
approach is to create an alias and tie it to a physical machine with DNS. If you are
running a stand-alone machine, you can either use an alias tied to your machine name, or
use your machine name directory.
You can control the number of Gopher connections permitted at one time. This is
sometimes necessary to prevent a system from bogging down due to excessive user load. The
maximum number of connections Gopher permits is given in a file, usually in the directory
PIDS_Directory. A line in the gopherd.conf file usually has this variable commented out
because early versions didn't implement it properly, or it was unstable. If you want to
enable this feature, remove the comment symbol and make sure that the directory pointed to
has the necessary files for your version of Gopher. The line usually looks like this:
#PIDS_Directory: /pids
A better way to handle the load on your system is to use the MaxConnections keyword,
which sets the number of clients you support concurrently. You have to experiment to
determine the best balance between system load and user service. A good starting point for
a fast Linux system (80486 or Pentium CPU) is 15 to 25 users. This variable is set like
this:
MaxConnections: 15
You can set a number of file decoders for your system. This setting is used when a user
requests a file from Gopher and adds an extension (such as .Z, .gz, or .zip) for a
compression or archive utility. The decoders recognize the extension the user supplies and
invoke the proper utility to send the file in that format. Most gopherd.conf files have
the following decoder lines already in the setup:
decoder: .Z /usr/ucb/zcat decoder: .gz /usr/gnu/bin/zcat #decoder: .adpcm /usr/openwin/bin/adpcm_dec #decoder: .z /usr/gnu/bin/zcat
The last two decoders are commented out and can be uncommented if you want to offer the
programs through Gopher. You can also add other extensions, such as .zip, .tar, and so on
by adding new lines with the binary name (and its full path).
The amount of time a cache file stays valid should be set. This is controlled by the
line using the keyword Cachetime. Set this value to a reasonable value, such as 180
seconds. You should have a line that looks like this in the gopherd.conf file:
Cachetime: 180
You can use the gopherd.conf file to restrict access to some files on your system by
using the ignore keyword. Usually the gopherd.conf file has a number of defined ignores,
such as these:
ignore: lib ignore: bin ignore: etc ignore: dev
Any file with this type of extension is ignored. If you have a particular file
extension you want to protect, add it to the list. For example, if your accounting system
uses the extension .acct, you could have the Gopher clients ignore all these files by
adding this line:
ignore: acct
Note that these ignore statements work only with file extensions. To create a broader
search, you can use wildcards and the keyword ignore_patt (for ignore pattern). For
example, the following line will ignore any file with the letters usr anywhere in the
name:
ignore_patt: ^usr$
In the file gopherdlocal.conf, you have to make two small changes to identify the
system administrator. Otherwise, your system will generate lots of annoying notes. The
lines in the gopherdlocal.conf file look like this by default:
Admin: blank AdminEmail: blank
If you do not change these entries to actual values, Gopher can generate all kinds of
weird error messages. The Admin field usually has the administrator's name and sometimes a
telephone number. For example, the file could be filled out as follows:
Admin: Yvonne Chow, 555-1212 AdminEmail: ychow@chatton.com
Another setting you should provide in the gopherdlocal.conf file is the Abstract, which
is a short description of what your particular Gopher service provides. If you don't
change the default setting, users get a message prompting them to get you to set the
Abstract, so you may as well do it right away. Multiple lines in an abstract value are
followed by a backslash to show the continuation. A sample Abstract setting looks like
this:
Abstract: This server provides sound and graphics files \ collected by the administrator on a recent trip to Outer \ Mongolia.
General information about your site is provided with a number of general settings for
the site name, the organization that runs the site, your machine's geographic location,
the latitude and longitude of your site, and a timezone setting. You can leave these blank
if you want, but providing the information leads to a more complete Gopher site. The
settings in a sample gopherdlocal.conf file look like this:
Site: Explore_Mongolia Org: Mongolia Tourist Bureau Loc: North Bay, Ontario, Canada Geog: blank TZ: EDT
The setting of blank for Geog will leave the setting with no value. Obviously, the
system administrator didn't know the latitude and longitude settings.
You can set a language option used by Gopher clients to show what language most of the
documents available on your site are written in. For American English, for example, you
set the option like this:
Language: En_US
The setting BummerMsg is used to display a brief text string to a user who exceeds your
maximum number of concurrent users or causes an error when accessing the system. The
default value is the following:
BummerMsg: We're sorry, we6 don't allow off-site access to this server
You can change this to whatever message you want. Try not to be rude or obnoxious,
because you never know who will get this message.
The last step in modifying the gopherdlocal.conf file is to set access procedures for
users who log in to your Gopher server. By using entries with the keyword access, you can
limit the users who can get to your server. The general format of the access line is:
access: hostname permissions num_users
In this example, hostname is either the name or IP address of the host that is
connecting to your server, permissions is the permission set for those users, and
num_users is the maximum number of users that can be connected to the service
concurrently.
The permissions are set using any combination of the following four words, either as
they are or preceded by an exclamation mark to mean "not allowed." The
permission keywords are as follows:
For example, to set access permissions to allow up to 10 users from the network
chatton.com to access your Gopher server with full rights, you add a line like the
following:
access: chatton.com browse ftp read search 10
There is at least one space between each entry, even between permissions. Take a look
at this access entry:
access: bignet.org !browse !ftp read search 3
This entry allows three concurrent users from bignet.org to access the Gopher server
and read and search, but not use FTP gateways or browse the directory listings.
If you are using IP addresses, you can use a subset of the IP address to indicate the
entire network. For example, if bignet.com's network address is 147.12, you can indicate
the entire network with a line like this:
access: 147.12. !browse !ftp read search 3
You must follow the last quad of numbers specified in the IP address with a period,
otherwise 147.120 through 147.129 will also have the same permissions (because they match
the digits specified).
If you want to enable access from a particular machine, you can do that, too. For
example, to allow your friend's darkstar machine to access your Gopher server with full
permissions, you would add a line like this:
access: darkstar.domain.name browse ftp read search 1
Most general Gopher servers tend to allow anyone to connect, so they use a default
entry to refer to anyone not explicitly defined by another access entry. The default
setting is usually like this:
access: default !browse !ftp read search 15
This setting allows anyone to read and search Gopher directories, but not move through
them or use your machine as an FTP gateway.
You need to modify two files for the compilation process to proceed properly. These two
files are Makefile.config and conf.h. With many versions of Gopher available on Linux
systems, the configuration parameters these files need have already been set, but you
should check the values carefully to prevent problems.
The Makefile.config file (used by Makefile to build the executable) is a lengthy file,
so you should be careful moving through it to avoid accidental changes. The important
areas to examine are the directory definitions and server and client settings. These are
dealt with individually later in this section.
One setting you may want to alter is the debugging utility, which is enabled by default
in most systems. This can help you get the system running properly. When the operation is
correct, however, you should recompile the source with the debugging features removed to
make the process faster and smaller, as well as reduce debug information overhead. To
remove debugging features, comment out the DEBUGGING line so it looks like this:
#DEBUGGING = -DDEBUGGING
By default, this line is probably not commented out.
The directory definitions are usually in a block with five to seven entries, depending
on the number of entries for the man pages. A typical directory definition block looks
like this:
PREFIX = /usr/local CLIENTDIR = $(PREFIX)/bin CLIENTLIB = $(PREFIX)/lib SERVERDIR = $(PREFIX)/etc MAN1DIR = $(PREFIX)/man/man1 MAN5DIR = $(PREFIX)/man/man5 MAN8DIR = $(PREFIX)/man/man8
The primary change to most Makefile.config files will be the PREFIX, which is used to
set the basic directory for Gopher. The default value is usually /usr/local, although you
can change it to anything you want (such as /usr/gopher). The rest of the variables define
subdirectories under the primary Gopher directory, and they are usually acceptable as they
are. You can leave all of the subdirectories the way they are, or you can change them to
suit your own needs. You can place all the files in one directory, if you want. The
meaning of each variable is as follows:
| CLIENTDIR | Gopher client software |
| CLIENTLIB | client help file (gopher.hlp) |
| MAN1DIR | man pages for gopher client |
| MAN8DIR | man pages for gopherd |
| SERVERDIR | Gopher server (gopherd) and configuration file (gopherd.conf) |
For a Gopher client to run properly on your system, you must modify the CLIENTOPTS line
in the Makefile.config file. The two options for controlling the behavior of the
CLIENTOPTS line are as follows :
To use either or both of these options, add them to the CLIENTOPS line, like this:
CLIENTOPTS = -DNOMAIL -DAUTOEXITONU
You need to set four variables relating to the Gopher server. These variables specify
the host domain name, the port Gopher should use to listen for connections, the location
of the data files, and option flags.
The domain name is set with the DOMAIN variable. It should have a leading period in the
name, such as:
DOMAIN = .tpci.com
You do not need to set this variable if the hostname command returns the fully
qualified domain name of the server. In this case, leave the value blank.
The SERVERPORT variable defines the port Gopher uses to wait for services, and it is
usually set for TCP port 70. This line usually looks like this:
SERVERPORT = 70
If you are not allowing general access to your Gopher site by Internet users, you can
change this value. However, if you want to allow Internet users (even a very small subset)
to gain access, you should leave this as port 70. If you are setting up your Gopher site
for a small network only, then choose any port number you want (between 1024 and 9999) and
make sure all the Gopher clients use that number, too.
The SERVERDATA variable defines the location of the data your Gopher server offers. Its
default setting is usually like this:
SERVERDATA = /gopher-data
Set the variable to point to the file location you use for your Gopher items.
The SERVEROPTS variable accepts a number of keywords that change the behavior of the
Gopher service. A typical entry looks like this:
SERVEROPTS = -DSETPROCTITLE -DCAPFILES # -DBIO -DDL
Any keywords after the pound sign are ignored when Makefile runs, so you can adjust its
location to set the options you want if the order of the variables allows such a simple
approach. The meanings of the different keywords allowed in the SERVEROPTS entry are as
follows:
You can use the DLOADRESTRICT keyword instead of other mechanisms in the configuration
files for setting the maximum number of concurrent users. If you want to use
DLOADRESTRICT, you should also modify the conf.h file (see the next few paragraphs) and
make sure that the Makefile.config file has this entry:
LOADLIBS = -lkvm
Most Makefile.config versions have this line commented out. Remove the comment symbol.
The conf.h file is used during the compilation to set other parameters about the Gopher
service. The important settings, at least as far as setting up a Gopher service, are those
that relate to the number of queries and timeout variables. These tend to occur at the end
of the conf.h file.
The WAISMAXHITS variable defines the maximum number of hits a query to a WAIS database
can offer, usually set to around 40. This variable is defined like this:
#define WAISMAXHITS 40
Note that the pound sign is not a comment symbol, because this is written in C. The
pound sign is an important part of the processor directive and should be left in place.
There is no equal sign in the definition, either.
The MAXLOAD variable is used if the -DLOADRESTRICT keyword was used in the SERVEROPTS
variable of Makefile.config. The MAXLOAD variable defines the maximum load the Gopher
service can handle before refusing service (you can override this value on the command
line). The usual definition is like this:
#define MAXLOAD 10.0
The READTIMEOUT and WRITETIMEOUT variables set the amount of time a service waits for a
network read or write operation before timing out. The default settings are usually
adequate. These lines look like this:
#define READTIMEOUT (1*60) #define WRITETIMEOUT (3*60)
The Gopher client configuration is straightforward. Begin by defining the Gopher
servers the local machine is to connect to with the CLIENT1_HOST and CLIENT2_HOST entries.
The Gopher client will choose one of the two (if both are defined) when it is started. The
entries look like this:
#define CLIENT1_HOST "gopher_serv.tpci.com" #define CLIENT2_HOST "other_gopher_serv.tpci.com"
The ports to be used to connect to the hosts are defined with these options:
#define CLIENT1_PORT 70 #define CLIENT2_PORT 70
If you have a local service and don't want to use port 70 (to prevent access from the
Internet, for example), set the proper port values. If only one Gopher server is used, set
the second value to 0.
The language the Gopher client is to use is defined by choosing one value out of a
number of options. The default is American English, set by this command:
#define DEFAULT_LANG "En_US"
There are other language definintions commented out below this one. If you want to
change the default language, comment the American English setting and uncomment the one
you want.
When all the configuration changes have been made, you can invoke the compilation
process for the client and server with these commands:
make client make server
Or you can do both client and server systems at once by using the make command with no
argument. The installation procedure must be compiled, too, using the following command:
make install
After that, run the installation script and follow the prompts to install Gopher.
Gopher clients have the ability to use WAIS indexes to search for a document, but the
system must be configured to allow this. You looked at WAIS in the last chapter, so for
the sake of providing WAIS index access to Gopher, this section assumes that you have
installed WAIS properly and have WAIS indexes ready for Gopher.
To provide WAIS services through Gopher, you may have to make a change in the WAIS
source code. Examine the WAIS source code for a line that looks like this:
if (gLastAnd) printf("search_word: boolean 'and' scored/n:);
This line should be commented out to provide Gopher services. If it is not, add C
comment symbols before and after the line, like this:
/* if (gLastAnd) printf("search_word: boolean 'and' scored/n:); */
If the line was already commented out (or didn't exist), then you need not make any
change. If you changed the line, though, you have to recompile WAIS by changing into the
WAIS top directory and running the makefile (type the command make).
Next, examine the Gopher Makefile.config file and look for the WAISTYPE variable. It
should be defined on a line like this:
WAISTYPE = #-DFREREWAUS_0_4
Then you have to link the Gopher and WAIS services. Suppose your Gopher source
directory is /usr/gopher/source and the WAIS source directory is /usr/wais/source. You can
link these services by entering the following commands:
cd /usr/gopher/source ln -s /usr/wais/source/include ./ir ln -s /usr/wais/source/client/ui . ln -s /usr/wais/source/bin .
When Gopher is recompiled, it will make the links between Gopher and freeWAIS and allow
the two services to interwork.
Gopher directories and files are quite simple to set up, and they follow standard
naming conventions for the most part. Before you begin, though, you should know which
documents and files are to be provided through Gopher to others, and you should be able to
write a short description of each. (If you don't know the contents of a file, either read
it or get the author to summarize the file for you.) To begin, assume that you are using
only a single directory for all your Gopher documents.
Begin by changing to the top directory you use for your Gopher directories (which you
may have to create if you haven't already done so). This directory should not be where the
Gopher source and configuration files are located, for convenience. Simply choose a useful
name and create the directory. For example, to create the Gopher home directory
/usr/gopher/data, you issue a standard mkdir command:
mkdir /usr/gopher/data
Change into your Gopher directory and copy the files you want to make available into
it. When you have done that, you can create a descriptive filename for each file, instead
of the more obtuse filenames usually used, up to 80 characters long. For example, if you
have a file called q1.sales, you may want to rename it to Company_Sales_1887_Q1 to help
users identify the contents a little more easily. If you don't like this type of entry
(using underscores and other fillers because the shell doesn't allow spaces in a
filename), you can get even more elegant by using a .cap directory.
The process for providing better filenames is to first create a .cap directory under
your Gopher main directory (such as /usr/gopher/data/.cap). For each file in the main
directory, you want to create a file in the .cap directory with the same name, but with a
name and number. For example, suppose you have a file called q1.sales in /usr/gopher/data.
In /usr/gopher/data/.cap, you would create a file with the same name, q1.sales, which has
the following contents:
Name=Company Sales for the First Quarter, 1887 Numb=1
The Name entry can have spaces or other special symbols in it, as it is echoed as a
complete string. The Numb entry is for the location of the entry on your Gopher menu.
Suppose you had the entry just shown and two other files, shown by using cat to display
their contents:
$ cat q1.sales Name=Company Sales for the First Quarter, 1887 Numb=1 $ cat q2.sales Name=Company Sales for the Second Quarter, 1887 Numb=2 $cat q3.sales Name=Company Sales for the Third Quarter, 1887 Numb=3
When these entries are displayed in a Gopher menu, they look like this:
1. Company Sales for the First Quarter, 1887 2. Company Sales for the Second Quarter, 1887 3. Company Sales for the Third Quarter, 1887
The order of filenames in the .cap directory doesn't matter, but you shouldn't have the
same Numb entry more than once.
An alternative to using the .cap directory approach (which allows for easy addition of
new files) is to use a single master file for each document you are making available. This
file goes in your Gopher top directory and is called .names. Here's the .names file for
the same three files just mentioned:
$ cd /usr/gopher/data $ cat .names # My Gopher main .names file Path=./q1.sales Name=Company Sales for the First Quarter, 1887 Numb=1 Path=./q2.sales Name=Company Sales for the Second Quarter, 1887 Numb=2 Path=./q3.sales Name=Company Sales for the Third Quarter, 1887 Numb=3
As you can see, this format contains the same information but adds the filenames (which
were not needed in .cap because the filenames were the same). One advantage to using a
.names file is that you can reorder your menu entries much more easily because you only
have one file to work with instead of several. Also, the .names file enables you to add an
abstract describing the file. For example, you could have the following entry in a .names
file:
Path=./gopher Name=How to Set up A Gopher Service Numb=16 Abstract=This document shows the steps you need to take to set up a Gopher service.
You can get a little fancier with Gopher and have a menu item lead to another menu, or
to another machine entirely. You can do this with links, controlled by a link file, which
ends with .link. A .link file has five pieces of information in it, in the same format as
this example:
Name=More Sales Info Type=1 Port=70 Path=/usr/gopher/data/more_sales Host=wizard.tpci.com
The Name entry is what a user sees on the Gopher menu, and it can be any type of
description you want regardless of what else is in the link file. The Type field has a
number showing the type of document the file links to. Valid numbers are as follows:
| 0 | Text |
| 1 | Directory |
| 2 | CSO name server |
| 7 | Full text index |
| 8 | Telnet session |
| 9 | Binary |
| h | HTML file |
| I | Image file |
| M | MIME file |
| s | Sound file |
These types are the same as the list shown earlier in this chapter for the types of
files Gopher supports, although a little shorter.
The Port field is the port for a connection to a remote system (if that's where the
link leads), and the Path field is where the file is on the local or remote server. The
Host field, not surprisingly, is the name of the host the file resides on. If you are
setting up a link to another machine via FTP or WAIS, you need to specify the path to
include the service name and any arguments. For example, if your Gopher menu leads users
to a file on another machine through FTP, your link file may look like this:
Name=More Sales Info Type=1 Port=+ Path=ftp:chatton@bigcat.com/usr/gopher/cats Host=+
The plus sign used in the Port and Host fields instruct the FTP service on the remote
machine to return results to this machine using default ports (such as TCP port 21 for
FTP). For a link to a WAIS directory, the format is:
Name=More Sales Info Type=7 Port=+ Path=waisrc:/usr/wais/data Host=+
Finally, you may want to have a menu item execute a program. You can do this by having
the Path field use the exec command:
Path=exec: "args" : do_this
In this example, do_this is the program you want to execute and "args" are
any arguments to be passed to do_this. If you have no arguments to pass, leave the
quotation marks empty. This format is a little awkward, but it does work.
A Gopher server can be started either from the rc startup files, from the command line,
or from the inetd daemon. From the command line or the rc files, you will have a command
line similar to this:
/usr/local/etc/gopherd /usr/gopher/gopher-data 70
This line starts the daemon with the directory the startup Gopher menus reside in and
the port number for connections.
The gopherd command line accepts a number of optional flags to control its behavior,
although most flags mirror entries in the configuration files. The following are valid
flags:
| -C | Disables directory caching |
| -c | Runs without chroot restrictions |
| -D | Enables debugging |
| -I | Uses inetd to invoke gopherd |
| -L | Specifies the maximum load average when followed by a value |
| -l | Specifies log file to record connections (filename follows the option) |
| -o | Specifies an alternate configuration files from gopherd.conf (filename follows the option) |
| -u | Sets the name of the owner running gopherd (valid username must follow the option) |
To help secure your system, use chroot to create a separate filesystem structure for
the gopher area (as you did with FTP: see Chapter 43,
"Setting Up an FTP and Anonymous FTP Site"). The -c option is not as secure as
running gopherd with chroot active. Also, the -u option should be used to make gopherd run
as a standard user's process, instead of as root. This helps protect against holes in the
daemon that a hacker could exploit.
If you want to run Gopher under inetd (started whenever a request for the service
arrives), modify the /etc/services and /etc/inetd.conf file to include a line for Gopher.
Normally, the entry in /etc/services looks like this:
gopher 70/tcp
The entry in /etc/inetd.conf looks like this:
gopher stream tcp nowait root /usr/local/etc/gopherd gopherd -I -u username
In this entry, username is the name of the user to run gopherd as (you can set up a
specific account for gopher in /etc/passwd with standard permissions).
Once the Gopher server process is up and running, you can test your Gopher
installation. You will need a Gopher client. Use the Gopher client to connect to your
Gopher server (using your host name) and you should see the top directory of your Gopher
resources. Another way to test your Gopher system is to use Telnet. Use Telnet to connect
to the gopher port, using a command like this:
telnet gopher 70
If the connection is properly made, you will see your Gopher system on the screen.
Yet another alternative to test your system is to use the program gopherls, which
requires the name of the directory your Gopher source resides in. To start gopherls, you
issue a command like this:
gopherls /usr/wais/gopher/data
This command specifies your Gopher data directory. You can use this technique to test
new Gopher directories as you develop them.
Because you have spent a lot of time setting up your Gopher service, you can let
everyone else on the Internet know about it. (Of course, you should only do this when your
Gopher service is ready, and if you want to allow general access. Don't follow these steps
if you are granting access only to a few people or to your local area network.)
To have your Gopher service listed in the main Gopher service directories, send an
e-mail message to the address:
gopher@boombox.micro.umn.edu
Include the Gopher service's full name as it appears on your main menu, your host's
name and IP address, the port number Gopher uses (which should be TCP port 70 for general Internet access), the e-mail account of the Gopher administrator, and a
short paragraph describing your service. You can also provide a string that gives the path
to the data directory, if you want. Because most Gopher systems start in the root
directory, however, this string isn't needed unless you have sub-menus for different
purposes.
After you have done all that, your Gopher service should be ready to use. You need to set up the Gopher file entries, but that is beyond the scope of this chapter. Consult a good Internet or Gopher book for more information on Gopher directories, files, and entries. Gopher is a handy utility if you have lots of information you want to share. Although the configuration process can take a while, the Gopher system tends to work very well once it is completed.
